perm filename STEAM.ABS[P,JRA] blob
sn#573265 filedate 1981-03-21 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00003 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 ∂09-Jan-81 1503 BRoberts at BBNG (Bruce Roberts) Abstract for Computer Fair
C00008 00003 ∂20-Mar-81 1238 BRoberts at BBNG (Bruce Roberts) Presentation for WCCF
C00064 ENDMK
C⊗;
∂09-Jan-81 1503 BRoberts at BBNG (Bruce Roberts) Abstract for Computer Fair
Date: 9 Jan 1981 1802-EST
From: BRoberts at BBNG (Bruce Roberts)
Subject: Abstract for Computer Fair
To: jra at SU-AI
cc: stevens at BBNG, BRoberts at BBNG
As part of the STEAMER project, we have built a color graphics
interface to a large mathematical model of a ship's steam plant. With
it, one can watch any of several dynamic views of steam plant
operation and control the steam plant by adjusting valves and flipping
switches on the screen. The entire system is written in Maclisp and
runs on a Decsystem-20 with an AED 512 color graphics processor for
output and an Elographics touch panel for input.
A schematic view of the steam plant or one of its subsystems is
constructed out of a library of "icons", graphical objects that
contain all information necessary to draw and manipulate the object.
There are icons for various kinds of pumps, turbines, pipes, valves,
gages, motors, and other paraphernalia that compose a steam plant.
The multiplicity of objects, related in their functional
characteristics but differing in details of representation, was
brought under control by organizing them in a class hierarchy. By
thus compartmentalizing the knowledge about graphical objects, we find
that new objects are easy to add, that it is easy to substitute
different objects in a scene without disrupting the overall layout,
and that we have reduced to a minimum the amount of knowledge other
parts of the system need to have about the particulars of the
graphical interface in order to communicate through it.
Icons vary not only in their appearance, but in how they indicate
state. Many components of a steam plant are just "on" or "off"; an
icon might depict this by blinking, by its choice of color, or by the
position of some indicator within it. Continuous variables in the
steam plant simulation can be shown as the level of a column, the
needle on a dial, the value of a digital readout, or the blink rate of
an object.
An icon can be used for input by supplying it with a method to
interpret a touch at some point within its boundaries. A simple
on/off icon might return the state opposite what it is currently
indicating; an continuous icon indicator can return the value it would
show at the point being touched.
The communication between the math model and the display is mediated
by another class of computational object we are calling "taps". Taps
map from variables to an icon and back. They are necessary because
there is not a one-to-one relationship between the abstract entities
computed in the model and their visual counterparts. For example, the
notion of a component being "on" may be a complex function of many
variables in the simulation. Taps translate between the language of
the simulation (in this case, the values of particular Lisp atoms) and
the language of the display icons.
We will show a video tape of an interaction with the STEAMER system,
and of a graphics editor helping to construct schematic views of steam
plants. We will discuss the organization of our object-based display
system and the extreme advantages of adopting the object-oriented
paradigm for graphic systems, advantages multiplied by imbedding it in
a superior interactive language. We will touch on our plans to
develop STEAMER into an intelligent tutor in complex thermodynamic
systems.
-------
∂20-Mar-81 1238 BRoberts at BBNG (Bruce Roberts) Presentation for WCCF
Date: 20 Mar 1981 1520-EST
From: BRoberts at BBNG (Bruce Roberts)
Subject: Presentation for WCCF
To: jra at SU-AI
Here is the long-promised paper describing a Graphics Language
based on messaging-passing in MacLisp.
I plan to show a video tape (as we have discussed (3/4" color)) and
possibly some 35mm slides or viewgraph materials. A talk would
emphasize the inherent flexibility of message-passing for building
graphics systems.
----------------------------------------------------------------------
←←←←←←←←←←←←
Introduction
As part of the STEAMER project, we have built a color graphics
interface to a large mathematical model of a ship's steam plant.
With it, one can watch any of several dynamic views of steam
plant operation and control the steam plant by adjusting valves
and flipping switches on the screen. The entire system is
written in Maclisp and runs on a Decsystem-20 with an AED 512
color graphics processor for output and an Elographics touch
panel for input.
A schematic view of the steam plant or one of its subsystems is
constructed out of a library of "icons", graphical objects that
contain all information necessary to draw and manipulate the
object. There are icons for various kinds of pumps, turbines,
pipes, valves, gages, motors, and other paraphernalia that
compose a steam plant. The multiplicity of objects, related in
their functional characteristics but differing in details of
representation, was brought under control by organizing them in a
class hierarchy. By thus compartmentalizing the knowledge about
graphical objects, we find that new objects are easy to add, that
it is easy to substitute different objects in a scene without
disrupting the overall layout, and that we have reduced to a
minimum the amount of knowledge other parts of the system need to
have about the particulars of the graphical interface in order to
communicate through it.
Icons vary not only in their appearance, but in how they
! 1
indicate state. Many components of a steam plant are just "on"
or "off"; an icon might depict this by blinking, by its choice of
color, or by the position of some indicator within it.
Continuous variables in the steam plant simulation can be shown
as the level of a column, the needle on a dial, the value of a
digital readout, or the blink rate of an object.
An icon can be used for input by supplying it with a method to
interpret a touch at some point within its boundaries. A simple
on/off icon might return the state opposite what it is currently
indicating; an continuous icon indicator can return the value it
would show at the point being touched.
The communication between the math model and the display is
mediated by another class of computational object we are calling
"taps". Taps map from variables to an icon and back. They are
necessary because there is not a one-to-one relationship between
the abstract entities computed in the model and their visual
counterparts. For example, the notion of a component being "on"
may be a complex function of many variables in the simulation.
Taps translate between the language of the simulation (in this
case, the values of particular Lisp atoms) and the language of
the display icons.
GRAPHICAL OBJECTS IN STEAMER
GRAPHICAL OBJECTS IN STEAMER
A displayed view of the steam plant is constructed out of
carefully designed graphical building blocks, some of which
represent common geometric shapes, and some the more
! 2
idiosyncratic schematic notation used in steam plant drawings. A
view is not painstakingly laid out point by point and line by
line, but is built up from these component graphical objects,
some of which are shown in Figure 1. The following presents how
these graphical objects are implemented and connected to a
simulation of a steam plant.
←←←←←←←←← ←←←←←←← ←←← ←←←←←← ←←←←←←
Graphical←objects←are←called←ICONS.
The internal representation of a graphical object is called an
←←←←
icon, although it is natural to refer to the displayed image as
an icon too, since that is what one actually sees. Usually no
confusion arises between these two meanings, but it's important
to remember that icons can do more things than just display
themselves on a screen. The next section discussess in detail
the representation that underlies an icon's extended behavior.
Icons are organized into classes to maximize sharing among
objects that have similar characteristics. Figure 2 shows the
icons currently available for general use. ICON is the most
general object class. It defines the functionality common to all
icons, but has no shape. Four subclasses of ICON -- BOX, CIRCLE,
DIAMOND, LOZENGE (straight sides, rounded ends) -- have
noncommittal shapes. Three other subclasses of ICON -- PUMP,
VALVE, SWITCH -- represent common components of a steam plant in
their conventional schematic form, and are themselves further
differentiated into subclasses. These icons all can show
discrete states of the device they represent.
! 3
Figure 1:
Figure 1: A sampler of STEAMER graphical objects
! 4
|BOX
|CIRCLE
|LOZENGE
|DIAMOND
|SWITCH
| |CENTRIFUGAL-PUMP
|PUMP-----|
ICON--| |ROTARY-PUMP
|
| |STOP-VALVE
|VALVE----|CHECK-VALVE
| |RELIEF-VALVE
|
|BANNER |DIAL
| |GAGE---------|
|MEASURE--|ARROWS |COLUMN
|DIGITAL-BAR
Figure 2:
Figure 2: Icon classes
The remaining icons are designed to show continuously varying
values. A BANNER displays an arbitrary string of text. The
subclasses of the MEASURE icon -- ARROWS, DIGITAL-BAR, GAGE
(incorporating DIAL and COLUMN) display real-valued numerical
information. ARROWS icons are small arrowheads whose blink rate
can be varied; they are used to indicate flow in pipes. DIAL
icons serve as pressure gages and COLUMN icons as thermometers.
DIGITAL-BAR icons combine a digital readout with a column to show
directly change and relative magnitude within a prescribed range.
←←← ←←←←←←←← ←←←←←←←←← ←← ←← ←←←←
The←internal←structure←of←an←ICON
Icons possess a good deal of internal information besides the
basic geometric parameters needed to draw them. In particular,
all icons have the ability of dynamically alter some
characteristic of their appearance to indicate a changing
property of the system they are depicting.
! 5
Icons have a local coordinate system, a basic outline color, a
label, and a set of possible states (the defaults are ON and
OFF). Different states are typically associated with unique
colors (the defaults are GREEN and RED, respectively); a state is
indicated by flooding the area around each of a list of "fill
points" with its associated color. On many displays, blinking
colors are just another kind of available color, so blinking
icons are subsumed by this general notion of color.
The implementation of icons in our system supplies a precise
interpretation for the informal notion of a "class" we have been
using so far. Each icon class defines a set of named variables
and procedures. Classes are arranged in a hierarchy and both
variables and procedures are inherited by subclasses. Each
subclass can add new variables and procedures or modify the
meaning of the those appearing above it in the hierarchy. The
class definition describes a generic object of which any number
of instances can exist. Every instance will have its own local
variables and access to all the procedures defined for (or
inherited by) its class.
←←←← ←←←←←←←←←
ICON←variables
1
The following is a list of instance variables associated with
the general class ICON:
←←←←←←←←←←←←←←←
1
So called because, although their existence is dictated by the
class definition, they appear only in the instances themselves.
! 6
Coords A 4-tuple containing the rectangular coordinates
of the icon in its enclosing coordinate system --
(<X-left> <Y-bottom> <X-right> <Y-top>).
X-Orientation The orientation of the X axis: {[right] left up
2
down}. "Horizontal" and "vertical" are also
allowable values for those icons symmetric about
one of their axes.
Y-Orientation
The orientation of the Y axis relative to the X
axis: {[left] right}.
OutlineColor
The color to use for the outermost edge of
3
object. "WHITE" is the default.
StateIndicators
A list of pairs of states and associated colors;
the default is ((ON . GREEN)(OFF . RED)).
State
The state currently being shown.
Fillpoints
4
A list of points in a 0->1 coordinate system
local to the icon. These points identify regions
to be filled when flooding the icon with a color.
Label
A line of text.
LabelFont
One of the set {small, [medium], large}.
LabelColor
A color for the label. "WHITE" is the default.
←←←←←←←←←←←←←←←
2
"{...}" will be used to denote a set of alternatives. Any
default value is enclosed in square brackets.
3
The standard choice of colors is from the set {black white red
green blue yellow cyan magenta}.
4
Points are represented as a list of X and Y coordinates.
! 7
LabelPosition
One of the set {left right top bottom [center]}.
LabelOrientation
One of the set {vertical, [horizontal]}.
As we have said above, each icon class also has procedures
associated with it that collectively define the range of behavior
of its instances. Every icon must be able at least to draw and
erase itself from the screen, modify its appearance to indicate
its current state, determine whether a point on the screen lies
within it, and highlight itself. To achieve this, one does not
write procedures to manipulate icons; rather one writes
procedures that become part of the icon to perform on demand the
actions needed. Each of these actions is then given a name by
which it can be invoked for a particular icon.
The name of an action serves as a key to select among all the
procedures defined for an icon. Actions may involve manipulating
the icon in some fashion or returning some information about the
icon; the coordinates of its center, for example. The meaning of
a key is constant across all icons, although the implementation
of it may differ from icon to icon. The hierarchical
organization of the icon classes eliminates the need to duplicate
the definition of an action for each new subclass. Methods
shared by all icons need only be defined once for the ICON class.
They will then be inherited by all other icons. New methods can
be introduced in any subclass and thereby become available to all
of its subclasses further down in the hierarchy.
! 8
Icons can differ sufficiently that new procedures have to be
defined to perform the same actions in different icons; but since
the associated keys are held in common, an icons's user is
forever freed from knowing the peculiarities of each one.
Careful design of the icon hierarchy and the strategy of breaking
complex actions into many smaller ones, whose definitions can be
shared, can maximize the sharing of procedures among icons.
←←← ←←←←←←←←←←←←←←← ←←←←←←←←←←←←←← ←← ←←←←←
The←message-passing←implementation←of←icons
Communication with icons is carried on within a message-passing
paradigm. As implemented, icons are autonomous objects having a
well-defined recognizable datatype and possessing some amount of
local storage. "Messages" are "sent" to objects to invoke some
action or return some result. A primitive SEND function in Lisp
has as its arguments an object (an icon), a message (the key
associated with an action), and any number of additional
arguments which will be seen as arguments by the function
indirectly invoked by the message. The value of the SEND is the
5
value of the function.
The explicit existence of typed objects, the maintenance of
local storage, the inheritance and consequent sharing of
procedures, the possibility of defining generic operations over
←←←←←←←←←←←←←←←
5
Not all message-passing implementations enforce this
deterministic recursive behavior on the act of sending a message.
For example, an explicit continuation might be passed along with
the message; then the sender can continue immediately with
further computation, leaving the requested action to be performed
as in independent process.
! 9
large classes of objects, the ease of defining a consistent
semantics for the behavior of these objects -- all are advantages
of the message-passing framework. Our experience has been that
the mental reconceptualization forced upon a user of this system
greatly aids the design, modification, extension and use of the
great variety of graphical objects that are needed to depict a
steam plant.
←←←← ←←←←←←←←←←
Icon←procedures
Icons in general handle the following messages ("*" means the
argument is optional):
DRAW <arg>* Initializes the icon by assigning defaults to
missing values of instance variables and
computing any derived variables therefrom. The
icon then proceeds to actually draw itself. This
6
it does by sending itself the REDRAW message,
passing along its argument. Nothing is assumed
about the state of the current display or of the
existing internal representation.
REDRAW <arg>*
Assumes the state of the icon is correct but
nothing about the state of the current display.
It is responsible for drawing the static portion
of the display based on existing stored
information. Having done so, it then sends
itself the SHOW message, passing along its
argument as the first argument to SHOW and T as
the second.
SHOW <arg> <flag>*
←←←←←←←←←←←←←←←
6
The functions that define the methods for handling messages
are called, by convention, with their first argument bound to the
object that received the message. In this way, a method has
access to the object for which it is processing the message and
can do its own "sends" to the same object. The argument is
supplied by the message-passing machinery when the method is
called.
! 10
Redraws the dynamic portion of the icon to
indicate the new state passed as its argument,
and saves this in the STATE instance variable.
It assumes the old value of the STATE variable is
the one actually being shown at the moment and
does nothing if the new state matches the old
state. On the other hand, when <flag> is non-
null, the new state is drawn regardless of what
the icon has recorded about the current value.
The SHOW method supplied in ICON for indicating
state sends itself the FILL message specifying
the color obtaining from the STATEINDICATORS
instance variable.
ERASE
Erases the icon from the screen.
FILL <arg>
Floods with <arg> color regions of the icon
located at each of the X,Y coordinates in the
list of FILLPOINTS.
DRAW-LABEL
Prints an icon's label in <arg> color.
ERASE-LABEL
Erases an icon's label.
TOP
Returns the X,Y coordinate of the "top" of the
icon. The method defined for ICON returns the
midpoint on the rectangle in which it is drawn.
BOTTOM
Analogous to TOP.
LEFT
Analogous to TOP.
RIGHT
Analogous to TOP.
CENTER
Analogous to TOP.
COORDINATES <X-Left> <Y-Bottom> <X-Right> <Y-Top>
Assigns a coordinate system to icon. The
arguments define a rectangle within which the
icon is drawn.
STATES
! 11
Returns a list of states the icon can indicate.
COLORS
Returns a list of colors the icons can use to
indicate its various states.
ZOOM <arg>
Zooms in on the icon if arg is T; else unzooms.
BORDER <arg>*
Draws a border around the region using
OUTLINECOLOR, or optionally using <arg> as a
color.
CLAIM <arg>
Returns the icon as a value if and only if <arg>,
a tuple specifying a point, is inside the object.
TO-SHOW <arg>
Returns the a value that could be accepted by the
SHOW message to cause the icon to indicate the
state implied by <arg>, a point in the object.
The TO-SHOW method defined for ICON finds the
state in the list of STATEINDICATORS following
the one currently being shown by the icon (saved
in STATE) and returns the associated value. GAGE
icons, which move an indicator an the screen,
have a TO-SHOW method that returns the value that
would cause the indicator to point to the <arg>
location.
Having made this distinction between instance variables and
methods, we will now proceed to ignore it. The distinction is
present in the implementation and is important when one is
designing an object, but not in one's use of the objects that
have been defined. In practice, what is most important is the
semantics understood to underlie each message sent. Messages
that produce side-effects, like erasing an object from the
screen, are plainly activating procedures to accomplish their
task; however, many messages interrogate the object to return
some needed piece of information and the manner in which they
! 12
accomplish this (by variable lookup or computation) is
incidental.
The variables and procedures described above underlie the basic
functionality of all icons. Some of the specialized icon classes
listed in Figure 2 require additional variables and slight
redefinitions of the standard procedures. Below, we will briefly
describe some ways in which ICON class is augmented by its
subclasses.
←←←←←←←←←←← ←←←←←
Specialized←icons
Icons possessing general shapes (BOX, CIRCLE, DIAMOND, LOZENGE)
have no special properties beyond what have been detailed for
ICON. They behave alike except for their shape. PUMPs, VALVEs
and SWITCHes have asymmetries which make the specification of
their orientation critical.
The graphics language on which icons are built supports
coordinate system transformation: mapping of coordinates to
provide scaling and translation, reflection and rotation. Icons
are assumed to be drawn inside a rectangular region on the screen
whose size is determined by the values specified in the
COORDINATES message. The code that draws the icon does so in a
rectangular coordinate system of its own choosing (usually 0->1)
and the mapping from the definition coordinates to the actual
coordinates is done when the icon is drawn. Two variables -- X-
ORIENTATION and Y-ORIENTATION -- specify, within the coordinate
system, the direction of the positive X axis (normally to the
! 13
right) and the direction of the positive Y axis relative to the X
axis (normally to the left; that is, looking out the X axis
places the Y axis on your left). Figure 3 shows a swing check
valve drawn in each of its eight possible orientations, one for
each pair of X-ORIENTATION and Y-ORIENTATION values.
Figure 3:
Figure 3: Possible orientations of a Swing Check Valve.
The messages TOP, BOTTOM, LEFT and RIGHT are defined to
facilitate connecting icons together: they return a point on the
perimeter from which one might draw a pipe. These messages are
redefined for the CENTRIFUGAL-PUMP icon class to return the point
matching the location of the outlet of the pump as necessitated
by its orientation (see Figure 1). These new methods with the
same key name shadow and thus override the general methods
defined in ICON.
To accommodate the many styles of valves, a CONSTRUCTION
variable is added to each of the VALVE classes (for example,
! 14
check valves can be "lift", "swing" or "globe" construction; stop
valves can be "globe", "butterfly", or "gate" construction).
BANNER is an icon for printing arbitrary text at a fixed
location on the screen and so has been augmented to have FONT and
FORMAT-STRING variables. Its SHOW method simply prints its
argument in the specified FONT under control of the FORMAT-
STRING.
The MEASURE icon introduces into the hierarchy the notion of a
continuously varying numerical quantity. All MEASURE icons have
four additional instance variables:
Value The value current being shown by the icon (like
its STATE).
ValueJND A SHOW will not be done for differences between
old and new values less than this amount.
MinValue Minimum value the icon can indicate.
MaxValue Maximum value the icon can indicate.
DIAL and COLUMN icons have considerable detail in them and
require several new variables to specify:
Units A label showing the units of the measure. It
will be printed on the gage face.
Divisions A list of up to 3 integers specifying the number
of divisions to be indicated on the face of the
gage. For example, a gage with MINVALUE = 0.0,
MAXVALUE = 30.0, and DIVISIONS = (3 2) will have
a face reading from 0 to 30 with major tick marks
at 0, 10, 20, 30 and intermediate ticks at 5, 15,
25.
NotLabelDivisions?
If non-null, disables printing of any division
markings. This can produce, in the case of
COLUMN, a solid varying bar of color; since the
! 15
face will not be use to indicate units or
divisions.
In addition, various colors can be specified (FACECOLOR,
TICKCOLOR), as well as the font used for writing on the face of
the gage (FACEFONT). DIAL icons have a needle that swings over
an arc stored in the TOTALARC variable (default is 270.0).
The ARROWS icon is a composite icon with an added CHILDREN
variable to hold the names of its constituent ARROW icons (which
in turn have a PARENT variable). Only geometric information is
distributed in the ARROW icons: their individual coordinates and
orientation. All other ARROW instance variables are ignored.
Common information is in the ARROWS icon: the current indicated
value, the color to blink, the range, and so on. One
communicates only with an ARROWS icon. An ARROWS icon in turn
communicates with its children, who have had most of their
methods stripped away: one can't directly send DRAW and SHOW
messages to an ARROW.
←←←←←←←← ←← ←←←←
Creating←an←icon
A icon is created by instantiating an icon class and supplying
this new "instance" with the information relevant to icons of its
type. Most characteristics have defaults values to minimize the
amount of information that must be given to draw common cases.
The following is a typical excerpt of code to define a valve:
! 16
(setq V23 (instance valve-icon-class
construction 'globe
x-orientation 'down
label "Gland Seal Steam"
labelposition 'right
labelfont 'small))
The function INSTANCE creates an instance of VALVE-ICON-CLASS,
a Lisp variable whose value is the class. In addition, a number
of "sends" is done to incorporate information about the valve V23
7
in the newly created instance.
The only truly necessary piece of information lacking is the
coordinates for valve V23. One could explicitly install them
with the COORDINATES message; however, in practice other
facilities are available for fixing the geometric location of the
icon. A graphic editor that gives the designer the ability to
point to the position on the screen where V23 should go can send
the appropriate coordinates.
Not all information about V23 has to be supplied at once, and
if, for example, redesign suggests that a larger label would look
better, another message can be sent to change it --
(SEND V23 'LABELFONT 'MEDIUM).
Once the V23 has been defined, it is simply drawn and updated:
←←←←←←←←←←←←←←←
7
The names of the instance variables are implicitly "quoted",
producing the equivalent to a series of forms resembling
(SEND V23 'LABELFONT 'SMALL).
! 17
(SEND V23 'DRAW 'ON) ; its initial state is ON
.
.
.
(SEND V23 'SHOW 'OFF) ; now indicate OFF
←←←←←←←←←← ←←←←← ←← ← ←←←←←←←←←←
Connecting←icons←to←a←simulation
The icons we have been discussing embody a great deal of
knowledge about drawing, and some that enables them to react to a
8
stimulus. This section treats the problem of hooking up the
icons to a simulation, in this case, a math model of an operating
steam plant.
←←← ←←←←←←←
TAP←objects
A class of objects called taps serves as the nexus between the
icons and the variables manipulated by the math model simulation
as Figure 4 shows; taps are the sole interface between the world
of graphical objects (gauge, valve, column, pump) and the world
of simulated real-time values X ...X . In practice, a particular
1 y
icon is chosen that best depicts some conceptual quantity
computable from a variable or constellation of variables in the
simulation. When the variables change, the icon must be sent an
updated value to "show". Conversely, the icon, when touched,
returns a potentially "showable" value that must be converted
into some change in the controlling variables in the simulation.
←←←←←←←←←←←←←←←
8
In the complete system, a touch panel lies over the screen to
receive input. A touch is translated into a point in the screen
coordinate system and the visible icons are polled to find one
that "claims" the point as its own.
! 18
Two messages understood by taps, PROBE and SET, correspond to
these two cases.
Figure 4:
Figure 4: Taps connect the math model to the icons
Taps store three important pieces of information:
Icon An icon manipulated by the tap.
P-form A Lisp form evaluated when the tap is probed; its
value is sent to the icon as the argument to a
SHOW message.
S-form A lisp form evaluated when the tap is set with
"VALUE" freely bound to the argument received in
the SET message. As a special and common case,
an atomic S-form is interpreted as a symbol to be
"setq-ed" to the new value.
The following messages can be sent to taps:
READ Returns the value obtained by evaluating the P-
form.
! 19
PROBE Evaluates the P-form (by sending itself the
message READ) and then sends its icon this value
to SHOW. Literally, it does the following:
(SEND (SEND SELF 'ICON) 'SHOW (SEND SELF 'READ))
SET <arg> Binds "value" to <arg> and evaluates the S-form.
CLAIM <arg> <arg> is a coordinate pair. The taps's icon is
returned if it claims the point.
INIT <arg> Sends the DRAW message to its icon and does an
initial PROBE.
SET? Returns T if the tap can be set.
PROBE? Returns T if the tap can probe.
Subclasses of the general TAP icon provide convenient mapping
between the values returned from PROBE and the value sent to the
icon to SHOW; and conversely from the SET argument to the value
actually bound while evaluating the S-form. For example, while
the state of valves in the simulation is represented by the two
values T and NIL, it is more convenient and less confusing to
label the valve icon states OFF and ON. The BINARY-TAP class
performs this mapping automatically, letting one SET a valve
"ON", for instance. Figure 5 lists the tap classes.
|DISCRETE-TAP----|BINARY-TAP
TAP----|
|CONTINUOUS-TAP
Figure 5:
Figure 5: Tap classes
Discrete taps store an explicit mapping as a list of paired
math model states and icon states. Binary taps have this
predefined to map "OFF" to "NIL" and "ON" to "T". Continuous
taps can map a range of real numbers in the math model linearly
! 20
onto the range 0.0 to 1.0.
←← ←←←←←←←
An←example
One simple example will serve to convey the flavor of using the
combined notion of icons and taps to produce an interactive
graphical display of a simulation. The following short program
segment specifies the icon and associated tap for a simulated
pump. The necessary geometric information has been omitted,
since that would be specified indirectly using an editor for
laying out collections of icons.
(setq ICON:LubeOilPump ;A name for the icon, an
(instance rotary-pump-icon-class ;instance of a rotary pump.
StateIndicators '((OFF . RED) ;It shows three states
(STANDBY . YELLOW)
(ON . GREEN));with three colors.
Label "LOSP" ;It has a label,
LabelPosition 'left ;on its left,
LabelOrientation 'vertical) ;written vertically.
(setq TAP:LubeOilPump ;A name for the tap, which
;maps between discrete values.
(instantiate-discrete-tap-class
'LOPumpStart ;Probes the value of a single
'LOPumpStart ;variable and sets it also.
ICON:LubeOilPump ;The tap's icon.
'(OFF STANDBY ON) ;Values from "probe" and to "set",
'(-1 0 +1))) ;which correspond to these values
;in the math model.
Once the icon and tap have been so defined, they are
manipulated while running the simulation by periodically sending
appropriate messages to the tap. The tap mediates all
communication with the display and with the math model.
! 21
(SEND TAP:LubeOilPump 'INIT) ;Draws pump icon.
.
.
(SEND TAP:LubeOilPump 'PROBE) ;Updates the pump icon.
.
.
(SEND TAP:LubeOilPump 'SET 'HIGH) ;Turns the simulated pump
;on high (and updates the
;icon accordingly).
! xxii
List of Figures
List of Figures
Figure 1:
Figure 1: A sampler of STEAMER graphical objects 3
Figure 2:
Figure 2: Icon classes 4
Figure 3:
Figure 3: Possible orientations of a Swing Check Valve. 13
Figure 4:
Figure 4: Taps connect the math model to the icons 18
Figure 5:
Figure 5: Tap classes 19
-------